Devices & telemetry — data workflows
1Reading the diagrams
Each entity is a state machine: a green entry arrow marks creation, boxes are states (tone = kind), arrows are transitions. The table beneath spells the operation, the actor, and the event · rule · process behind every transition.
2Entity lifecycles
Telemetry & door-access are runtime, not a persisted lifecycle. The device-detail multi-metric stack (PTL-1, SPEC-UIX-DEV §7.1) renders live time-series — return / supply / ambient air, humidity, power, COP — and the front · back · side door open/close intervals. These live in the time-series plane outside Postgres (PTL-1 ⚠) and have no create/update/retire state machine of their own, so they add no entity here. A door held open past its 5-min threshold is evaluated into an Alert — whose lifecycle (active → acknowledged → cleared) is the mapped one below — so the door incident enters the data model only as that Alert, never as a stored door-event row.
3Lifecycle rules in play
The data-workflow invariants that bind this context — the master holds the full set.
4Revision history
| Version | Date | Changes |
|---|---|---|
| 0.1 | 27 Jun 2026 | First draft — Devices & telemetry entity lifecycles mapped as part of the new SPEC-DWF set: states, transitions and the event · rule · process behind each, all from the central catalog. |
| 0.2 | 2 Jul 2026 | Telemetry & door-access scope note (§2). Clarified that the device-detail multi-metric stack's live time-series (return / supply / ambient air, humidity, power, COP) and front · back · side door open/close intervals are runtime — outside Postgres, no create/update/retire lifecycle — and enter the model only via the Alert lifecycle when a door is held open past its 5-min threshold (PTL-1, SPEC-UIX-DEV §7.1). No new entity, state or transition. |